Use unique_ptr, not auto_ptr #13820
Use unique_ptr, not auto_ptr #13820
Conversation
|
A new Pull Request was created by @wmtan for CMSSW_8_1_X. It involves the following packages: DataFormats/Common @smuzaffar, @Dr15Jones, @cvuosalo, @cmsbuild, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
|
please test |
|
The tests are being triggered in jenkins. |
| template< typename T> struct OneHolder< std::auto_ptr<T> > { | ||
| typedef std::auto_ptr<T> Type; | ||
| template< typename T> struct OneHolder< std::unique_ptr<T> > { | ||
| typedef std::unique_ptr<T> Type; | ||
| OneHolder() {} |
There was a problem hiding this comment.
Shouldn't we keep the auto_ptr and make another specialization for unique_ptr?
There was a problem hiding this comment.
@Dr15Jones I don't know if auto_ptr is still needed, but to be safe, we'll keep it.
|
-1 Tested at: d96eae8 ---> test runtestTqafTopEventSelection had ERRORS you can see the results of the tests here: |
cmsbuild
added
tests-pending
comparison-pending
and removed
comparison-available
tests-rejected
labels
|
Pull request #13820 was updated. @smuzaffar, @Dr15Jones, @cvuosalo, @cmsbuild, @slava77, @davidlange6 can you please check and sign again. |
|
@Dr15Jones Converted to std::make_unique everywhere in the core software where it made sense and did not cause a build error. I did not spend time investigating build errors caused by std::make_unique. I just did not use make_unique in those cases. |
|
2cmsbuild please test |
|
please test |
|
-1 Tested at: c0684d0 ---> test runtestTqafTopEventSelection had ERRORS you can see the results of the tests here: |
|
@cmsbuild @davidlange6 The test failure is in the base IB and has nothing to do with this PR. |
|
+1 |
Replace almost all uses of std::auto_ptr with std::unique_ptr in the framework. Two packages outside the framework are minimally affected.
Other minor C++ improvements were made in a very few files that were modified anyway.
There are three places in the framework where use of std::auto_ptr remains in place for now, because
many packages outside the framework would have been affected. These are:
a) The put() interface, for Event, Run, and LuminosityBlock.
b) The interface to the EventSetup system
c) The use of OwnVector
These still support both auto_ptr and unique_ptr for now, and will be migrated solely to unique_ptr at a later time, if time permits.
Also, this PR adds the use of std::make_unique everywhere in the framework where it does not cause complications.
Unrelated to the above, I also fixed a few statements that had an extra semicolon at the end.